Azure Cloud Adoption Framework Handbook by Sasa Kovacevic & Darren Dempsey

Author:Sasa Kovacevic & Darren Dempsey
Language: eng
Format: epub
Publisher: Packt
Published: 2023-10-15T00:00:00+00:00

High availability but at what cost?

Without going into too much detail, just imagine the following scenario.

You have a service that kills a VM every 30–60 minutes on average. Let’s assume you didn’t know that it does that because you haven’t tested it properly, and you deploy that service to production.

Without high availability, that service will start fine but will then fail. So, let’s introduce some high availability patterns.

Restart the machine when it fails. There is some downtime during the restart. OK, let’s add a load balancer and deploy two VMs.

Given the 30–60 minute window, they could still both fail at the same time. OK, let’s deploy 10 VMs. You are now at 10 times your usual cost.

But let’s not stop here. This service is needed globally, so you introduce it to four different customer regions across eight different Azure regions (four pairs of paired regions). We are now at 80 VMs globally. Not only do you pay unnecessarily for all these but you also pay the increased cost of operations for a team that manages this infrastructure, you get alarms for restarts and spin-ups of VMs, and you make noise for everyone in the system, who now need to cross-check every error with the restarts of the VMs to see whether that was the cause.

Let’s also suppose that the service, when working correctly and not randomly dying every 30–60 minutes, can handle all the requests on just one VM. So, you deploy eight in total, one in each of the paired regions, and you pay less and don’t annoy your developers, your operations team, and your customers (because, remember, customer requests are failing and have to be retried) – all in an effort to avoid properly testing your service.

At this point, you have to ask yourself, how crazy am I? The answer, of course, is very.

And worst of all, this isn’t a theoretical issue. I’ve seen this issue in so many customers’ environments due to their lax testing practices.

This example was just that – an example of high availability, and how there might be cheaper and easier alternatives to it. This was emphatically not an example of a cloud native pattern. We’ll get to those quickly, I promise.

Availability sets: These serve as protection against hardware failures by distributing the load across more than one identical VM. These are distributed across multiple fault domains (fault domains do not share power and networking).

Availability zones: These are physically separated zones within an Azure region. Zones consist of multiple physical data centers, and they are separated and do not share power, cooling, and networking. This helps protect against data center-wide failures.

Azure regions: These are regions around the globe that provide Azure services. They consist of multiple data centers.

Azure paired regions: Azure regions that are paired are located in the same geography, and they are distant enough from each other such that a potential failure in one does not impact the other. In addition, Microsoft guarantees that software updates to Azure services will not happen to both paired regions at the same time, ensuring further resiliency.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.